 |
| Test team must review the Architecture Diagrams to ensure that the design match the requirement needs and verify the completeness of architectural views. |
| Disciplines: Technical Reviews |
|
Purpose
| Software design walkthrough is held to ensure adequacy, technical feasibility, completeness of the design, as well
as ensure the design match with the requirement needs. |
Relationships
| Roles | Primary Performer:
| Additional Performers:
|
| Inputs | Mandatory:
| Optional:
|
| Outputs |
|
Main Description
This activity basically comprises a meeting in which stakeholders involved with the SPL Design and Testing
activities are invited to inspect the artifacts produced in the Design phase and point out possible defects
and opportunities for improvement.
In design walkthrough, the test team must review the design documents and views to ensure that
the design match user and requirement needs. Team should also look for weaknesses or errors of style and ensure
that the software has been represented according to predefined standards. It also improves the understanding of the
test team regarding what is desired of the architectures.
In this activity, all architectural views are reviewed.
After performing the review, a detailed report is generated that lists items of concern regarding the design.
Design team should participate in this activity.
|
Steps
|
Plan for a Design Walthrough
This step serves as a guide to the design review activity. The plan is prepared in a meeting, in which the review
goals are established, as well as roles (basically: review leader [who will coordinate the review], author [one who
produced the artifact under review], reviewers, and recorder [responsible for the review report]), team size and the
right participants, i.e. stakeholders, are defined.
This is the initial step of Design Walkthrough. It should help define the key purpose of the walkthrough and
should provide practices and rules of conduct that can help participants collaborate with one another and add
value to the review. Moreover, the documents to be visited and reviewed must be listed.
|
Prepare Design Walkthrough
The Design Walkthrough should be scheduled accordingly, since the plan should include time for individual
preparation, the design walkthrough (meeting), and the likely rework. However, time to preparation should not
be long.
The responsible every document produced in the design phase, as being very familiar with the item under review, is
nominated the author. Its responsibility includes preparing a skilled presentation of the material aimed
at making the remaining team members able to build a comprehensive mental model of the item so that it is
possible to both evaluate its quality and detect defects.
Another in the team is nominated the review leader, who will actually later coordinate the progression of the
review.
|
Conduct Design Walthrough
In this step a meeting which the involved stakeholders will be held. The coordinator chairs the meeting.
In this meeting, the architect(s) responsible for designing the SPL is(are) supposed to present the material,
without influencing the reviewers into making the same logical errors as he did.
The reviewers can discuss the documentation in order to make suggestions where the material seems
flawed or has potential for extension. If, during the presentation, things are not clear enough, team members are
allowed to ask questions in order to clarify aspects of the presented material.
The basic principles of design, as established in the archictectural document, should be checked. Reviewers
must observe if the key mistakes that violate these principles are occurring. They must check the architecture of
the design for flaws, weaknesses, errors and omissions.
It is critical that the group remains focused on the task they are involved with. The coordinator can help in this
process by restraining unnecessary discussions and lead the group in the right direction. Moreover, the Coordinator
should resolve disagreements when the team can not reach a consensus.
|
Report the findings
After conducting the walthrough, all attendees must decide whether to accept/reject modifications in the artifact as
well as accept/reject the overall artifact. It will base the walkthrough report to be then produced.
A detailed report (Validation Report), including information regarding what was reviewed,
who reviewed, and what are the findings of the review is generated. It lists items of
concern regarding the requirements and use cases, i.e. problem areas within the product and corrections to be
made.
The Validation Report Template is available in Guidance folder.
|
|
Key Considerations
Besides the Architecture document, the architectural views are also reviewed in this activity.
The design walkthrough should be used as a means to review and critique the architecture, not the person
responsible for the design.
The major purpose here is to find defects. However, there may be times when participants drift from the main purpose.
The review leader, i.e. the moderator, needs to prevent this from happening and ensure that the walkthrough
focuses on the defects or weaknesses rather than identifying fixes or resolutions.
It is recommended to apply a time-box mode for the walkthrough. This will be helpful to avoid time wasting and/or
effectiveness loss.
|
|
